This PR will require that the latest release be updated on the LATEST_RELEASE travis env global as part of the release process for new angular.io updates.

@chalin can you review and tell me if this is what you intended?

I'm talking with @naomiblack for a way around the LATEST_RELEASE variable, but for now it works.

Great to see this move forward! Please see my comments below.

The check-deploy --dry-run essentially just does a harp compile. Defining and using a simpler target might make sense (in fact, I've been using such a target in my Dart API work):

gulp.task('check', ['build-docs'], function() {
  return harpCompile();
});

Note that scripts/install.sh is now part of our instructions to developers on how to install/reset their workspace. Could you ensure that you keep a copy of this file?

Actually, I think that we can simplify the situation by having a single install.sh script with conditional logic inside (defaulting to the install steps we had before). To accomplish this we might need a matrix something like this:

env:
  ...
  matrix:
    - TASK=lint
    - TASK='e2e --fast' PREVIEW=false
    - TASK='e2e --fast' PREVIEW=true
    - TASK='check' PREVIEW=false
    - TASK='check' PREVIEW=true
matrix:
  ...
  allow_failures:
    - env: "TASK='e2e --fast' PREVIEW=true"
    - env: "TASK='check' PREVIEW=true"
...
install:
  - ./scripts/install.sh

Then scripts/install.sh could have conditional logic based on the value of TASK. This is just a suggestion, but having a single install.sh file also makes it easier to assess the installation variants.

Btw, eventually we may also want to add checks on the output produced by the harp compile command to help determine if the check was truly successful or not.

Looking forward to having this in master.

@chalin thanks for the feedback! I think the simpler task for harp seems like a good idea, I'll put that in.

I don't think having a simple script with conditionals inside is a good idea though. It might default to what install.sh did, but that's not a one size fit all. In fact, that install.sh was only part of the install procedure - the bit that prepared the environment for authors (and only TS/JS ones I suspect).

That is why I renamed it to examples-install.sh. The only difference from before is that it doesn't do a base npm install --no-optional, which I agree we should add back for simplicity's sake.

I see the CI being expanded to also running dart if possible, but even in that case it's still useful to have the standalone scripts that setup your environment for what you need instead of having to setting flags locally to guide an install script.

Ah, I remember why I left npm install --no-optional out of examples-install.sh... because linting the project doesn't need the rest of the install procedure, but needs npm install --no-optional.

I'll update the readme to reflect that.

Updated the PR with a dedicated gulp task and updated readme.

LGTM

@naomiblack this PR still missing the latest release tag in angular/angular but it good otherwise. After it's in, we should look at triggering angular/angular.io CI on master when there is a angular/angular build.

cc @IgorMinar

Merging because @chalin and @filipesilva say so. Presumably they'll fix a busted CI.